These options let you open a pipe whose second end is connected to various
special hosts. (you only open these pipes once)
The X option is always followed by additional character(s). The second character determines what type of pipe is opened.
X0[(r|w)filename] (Programmable replacement)
Programmable replacement of a character. A single character is looked for in data written to the pipe and replaced by a multy character string.
First write two bytes to the pipe. the first byte is always '1' the second byte is the target character to be replaced. Then write a byte giving the length of the replacement string (<=255) followed by the replacement string. Do NOT include a terminating null .
Data written to the pipe after this point is echoed back to the pipe with any occurrences of the target character replaced by the specified string.
X0wfilename causes the data to be echoed to a file rather than back to the pipe.
X0rfilename causes the data to be read from a file rather than from the pipe. Note that the target character and replacement string is still read from the pipe not the external file. Only data to be parsed and replaced is read from the file.
THE THREE TOOLTYPE HOSTS
------------------------
Xt[filename] (find Tooltypes)
This host is the best suited to quickly check for tooltypes and get there values.
The icon file for the specified file (you do NOT add '.icon') is queried.
Open the file awnpipe:myname/Xt[filename]. Write a line containing the tooltype you wish to query to the pipe. Read back a response line.
If no icon file is found an eof is returned.
If the tooltype is NOT found you will read back a null line (only a <cr>).
If the tool type IS found you will read back 'ok ' followed by the tooltypes value (if it has one).
Xi[filename] (Icon information)
This host will retrieve fuller details about tooltypes and some other icon information. It is often used in combination with the following host.
The icon file for the specified file (you do NOT add '.icon') is read. The pipe returns the following lines...
icon_type x y stack
default tool
tool window
first tooltype
second tooltype
...
If no icon file is found no data is returned. Note that for blank lines will be returned when the information does not apply to that icon type.
To get information on a volume (say dh1:) use 'awnpipe:/xidh1:disk'.
Xs[filename] (Set icon information)
This host will alter or create the icon and tooltypes for the specified file.
Data is written to the host in the same format as returned by the preceding
host.
icon_type x y stack
default tool
tool window
first tooltype
second tooltype
third ...
Icon_type, x, y, and stack are all integer values written on a single line.
Default tool and the tooltypes are ascii strings.
Tool window is ignored but MUST still be included, either use a blank line ('0A'x) or used the data returned by the Xi host.
The first three lines are always required. You may set as many tooltypes as you like including none.
some useful information:
setting x and y to -2147483648 unsnapshots the icon.
icon_type 1=disk 2=drawer 3=tool 4=project
Xm[c][(r|w)filename] (pattern Matching)
Pattern match Conversation. This conversation supports full ADOS pattern matching. The trailing 'c' will make the match case sensitive.
Xmwfilename causes the match result to be sent to a file rather than back to the pipe.
Xmrfilename causes the data to be read from a file rather than from the pipe. The match results are read back from the pipe.
NOTE: the replies are ascii terminated with a newline.
Write the pattern to the pipe terminated with a newline. (<500 chars) The pipe returns 'ok 1' when you sent a valid pattern to match to. It returns 'ok 0' if you did not send a pattern ( the pipe will look only
for exact matches).
write a string to the pipe terminated with a newline.(<500 chars) read the reply '0' (no match) '1' (is a match)
write as many stings as you like . Close pipe to end. The terminating newlines are ignored while matching.
Xk (Keystroke filter)
Filter keystrokes from the input device event stream and receive notifications of the keystroke.
First write a byte to the pipe setting the priority of the key parse handler. It is a signed byte -128 to 127. If you are not sure what you want use 51 (0x33).
Next write a byte to the pipe indicating how many keystrokes to filter. The maximum is 255 (0x'ff'). 0 is NOT valid.
0x'0a' is 10 keys.
Then write two bytes to the pipe indicating how often a null match should be sent (to stop your task waiting forever for a match that never happens).
0x'0032' is 50/100s of a second.
Now write 4 bytes defining each key you wish to be notified of. The first two bytes are the key the second two bytes are the qualifier.
Writing 0x'00200001' to the pipe sets the 'a' key 'leftshifted' to be filtered from the event stream.
You MUST set exactly the same amount of keys as specified above.
Once the setup is complete you read notification from the pipe. Each notification is 1 byte giving a match number, the first keystroke you specified is 1, the second 2 ...
A byte of 0 is a null event, no match occurred.
Close the pipe to end key filtering. NOTE the keyparse handler actually does not get removed until the NEXT match or null event.
Xe (key Event generator)
Write keystrokes to the input device event stream.
Each keystroke is sent by writing 4 bytes to this pipe. The first two bytes are the key the second two bytes are the qualifier.
Writing 0x'00200001' to the pipe sends the 'a' key 'leftshifted'.
You may close the pipe at any time.
Xea (key events form Ascii)
Write keystrokes to the input device event stream from a string source.
Each keystroke is sent by writing a byte to this pipe. You do NOT need to write one character at a time. Simply write ascii text to the pipe and it will generate keystrokes as if the string had been typed at the keyboard.
This is easier than writing keycodes and qualifiers to the pipe but you can not generate 'special keystrokes' like Alt-F10 .
You may close the pipe at any time.
Xc[(r|w)filename] (ClassAct/Reaction host)
ClassAct Window Conversation. The Window and gadgets are defined by writing to the pipe:. Gadget hits and error/confirmation information is read from the pipe. A filename may also be given. If the file is specified as write 'w' the output of the pipe is directed to that file. If the file is specified as read 'r' the window and gadget definitions are read from the file.
See the GUI Creation section of the docs for details.
